Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@PhilippeWeidmann I made changes to be certain this is not a breaking change in pure Swift6 mode while maintaining thread safety. In 5.8 mode, it was not an issue.

Open to discuss this tomorrow @PhilippeWeidmann
We do not wait unless an unlikely call is made at the exact same time from another thread.

It is super unlikely, it exists in one place on the Drive App.
It does not append on the Mail app to my knowledge as most things are @mainActor

If we do not wait during this unlikely event, this is a bug that breaks the "thread safety contract" of this library.

I'm open to create a @mainactor property wrapper if you want to migrate Mail on it, but that is a feature that should be done separately IMO.
Also, you can refrain from using the lazyInject if you want a resolution made at the exact init of the object in the same thread.

Maybe we should put in context how long you wait, only the time needed for the resolution to be performed.
The resolution is a O(1) operation (fixed time, dictionary object for key call).
Worst case the UI waits for a resolution, plus some latency, it should not stall the UI thread, or any thread.
We rely on this resolution massively in our apps, it is not stalling our apps today.

Finally, the resolution engine already runs on a serial queue, so technically today the main thread waits already.

If what you wish for is a nice Swift6 interface that prevents issues at compile time, this is not ready or built that way and requires a near complete rewrite.

After live review we will merge this PR as is. Property wrapper used in view bodies in Mail will be modified to not be lazy.